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(57) ABSTRACT 

A financial transaction system. The present invention 
includes a method for performing a financial transaction, 
wherein a cardholder makes a purchase from a merchant 
using credit established at a financial institution. The method 
begins when the merchant transmits a merchant offer includ- 
ing merchant information about the purchase to the card- 
holder. The cardholder transmits the merchant information 
along with cardholder information to the financial institu- 
tion. The financial institution then transmits payment for the 
purchase to a merchant account and sends a payment noti- 
fication to the merchant indicating that payment for the 
purchase has been made and that the merchant offer has been 
accepted. 
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FINANCIAL TRANSACTION SYSTEM 

CROSS-REFERENCES TO RELATED 
APPLICATIONS 

This application claims priority from co-pending U. S. 
Provisional Patent Application No. 60/162,651 filed Nov. 1, 
1999. This application also claims priority from co-pending 
U.S. Provisional Patent Application No. 60/174,299 filed 
Jan. 3, 2000. Each of these applications are herein incorpo- 
rated in their entirety herein for all purposes. 

FIELD OF THE INVENTION 

This invention relates to financial transaction systems, 
and more particularly, to a system for conducting financial 
transactions over a computer network. 

BACKGROUND OF THE INVENTION 

Financial transactions conducted via computers and com- 
puter networks are susceptible to fraud or theft of confiden- 
tial financial information. Computer software engineers con- 
tinuously strive to improve the security of computer systems 
in an efTort to prevent theft and thereby calm users' fears. 
Various encryption schemes have been used to provide a 
layer of security for confidential information, however, for 
every effort toward increased security, new techniques are 
developed by hackers to break into encrypted information. 
Specifically, hackers want to steal credit card numbers and 
associated personal information. 

FIG. 1 shows how a typical credit card transaction is 
conducted over the Internet. A credit cardholder (purchaser) 
102, contacts a merchant's web site 104 over the Internet. 
The cardholder 102 makes a shopping selection from the 
merchant's web site as shown at 108. Next, the cardholder 
102 provides the merchant with a valid credit card number 
and related personal information, such as expiration date, 
shipping address and so forth, as shown at 110. 

The merchant 104 receives the cardholder's personal 
credit information and contacts the cardholder's credit card 
company 112 to charge the cost of the selected items, as 
shown at 114. If the charge against the credit card is 
successful, the merchant is notified and forwards an order 
confirmation 116 to the cardholder. The merchant then ships 
the selected goods to the cardholder. A short time later, the 
card company makes a payment to the merchant for the cost 
of the order as shown at 118. Finally, the card company 
provides a bill to the cardholder for the cost of the purchase 
and any accrued interest charges, as shown at 120. 

In the above example, it is easy to see that the cardholder 
has provided confidential information over the Internet to 
the merchant. There is a risk when a cardholder transmits 
this information, since it may travel through several com- 
puter systems prior to reaching the merchant. This places the 
information at risk of being stolen. The merchant stores this 
information in its internal database, and at some point, the 
information may be used to generate mailing lists for future 
product offerings. To generate additional revenues, the mer- 
chant may sell all or a portion of the information to third 
parties. Even if the merchant tries to protect the information, 
the merchant's database is subject to unauthorized access, 
which may also put the cardholder's personal information at 
risk. Although some merchants may take steps to prevent 
unauthorized access to their internal databases, other mer- 
chants may not use adequate security measures. As a result, 
the cardholder's credit card number and other personal 
information may be compromised. 
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Organizing merchants worldwide to adopt consistent 
security measures has been largely unsuccessful. The secure 
electronic transaction (SET) protocol; while having promise, 
has been abandoned by key players in the industry. At this 

5 point in time, secure socket layer (SSL) is the fall back 
position, particularly on the Internet. Other "pre-lnternet" 
problems continue to exist with regard to credit/debit cards. 
Employee theft, merchant fraud, recurring charges, and theft 
by others cause massive expense and hardship, such as with 

10 identity theft. These problems have had a chilling effect on 
electronic commerce. Reports estimate that 70%-80% of 
Internet purchases are left uncompleted. Either the card- 
holder backs out of the electronic transaction completely or 
telephones the company directly to verbally place the order. 

15 The threshold for merchants to accept and process credit 
card purchases remains high. Merchants, for the most part, 
still rely on phone and fax orders. They must buy terminal 
software and subscribe to third party processing companies. 
Internet merchants pay the highest discount rates and are 

20 limited to methods of shipping that require a signature 
evidencing receipt. Additionally, Internet merchants are 
unsupported in charge back disputes, which may occur if a 
product is shipped to an address other than the credit card 
billing address. 

25 SUMMARY OF THE INVENTION 

The present invention includes a financial transaction 
system that solves the problem of security for consumer 
credit card information transmitted over the Internet. The 

30 financial transaction system reverses the process with regard 
to card transactions conducted via computers and computer 
networks. Instead of cardholders transmitting their card 
numbers to merchants, the system obtains merchant infor- 
mation and requests that the cardholder's own card company 

35 pay the merchant. The cardholder's credit card number 
never travels across the Internet. The merchant never learns 
of the cardholder's card number. In one embodiment, only a 
shipping address is disclosed to the merchant, which comes 
directly from the card company along with a notification that 

4Q the payment has been made. 

Multiple user identifiers (IDs) and passwords can be 
assigned to different people to obtain credit from the same 
credit card. For example, the cardholder's own employees 
can be authorized to use the cardholder's credit card and 

45 never have to know the card number. The cardholder can 
delete or change user IDs as employees come or go or as 
family members gain or lose privileges. The user IDs can 
also be used to associate purchases with one or more 
shipping addresses that are different from the cardholder's 

50 billing address. 

When conducting transactions in accordance with the 
present invention, third party processing services are not 
needed. This eliminates multiple transmissions of personal 
credit card information across the network and the use of 

55 other vulnerable card number repositories having associated 
fees and staff. 

The invention provides an opportunity for the card com- 
pany to stop the transaction if either party is not validated, 
or if there is insufficient credit to cover the transaction. By 

60 inserting the card company at the front of the transaction 
process, many steps of the current transaction process are 
eliminated, including but not limited to, the steps of card 
verification by the merchant, address confirmation, payment 
submission, much of the charge back activity, and unautho- 

65 rized merchant recurring charges. 

In one embodiment of the present invention, a method is 
provided for performing a financial transaction, wherein a 
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cardholder makes a purchase from a merchant using credit FIG. 6 shows a diagram of a financial transaction system 

established at a financial institution. The method begins for making off-line purchases in accordance with the present 

when the merchant transmits a merchant offer including invention; 

information about the purchase to the cardholder. The card- FIG. 7 shows a method of operating the financial trans- 
holder transmits the merchant information along with card- 5 action system of FIG. 6; 

holder information to the financial institution. The financial nG 8 sbows a di ' of , financia , Uiasict i oa system 

institution then transmits payment for the purchase to a tha , ^ a card portal websjle in accor dance 

merchant account and send a payment notification to the ^ the Q , mveDtion; 

merchant indicating that payment for the item has been „.„ . , . , , , . 

made and that the merchant offer has been accepted. 10 . 9 shows a method of operalmg the financial trans- 

. ,. - . . . . , - action system of FIG. 8; 
Another embodiment of the present invention includes 

apparatus for use by a cardholder for conducting a financial HG * 10 shows a computer device suitable for use with 

transaction between the cardholder and a merchant, wherein embodiments of the present invention; 

the cardholder makes a purchases from the merchant using FI G- U shows components within the computer device of 

credit established at a financial institution. The apparatus 15 FIG. 10; 

includes, means for selecting an item to be purchased from FIG. 12A shows exemplary merchant transaction infor- 

the merchant, means for receiving information about the mation; 

selected item including a merchant identifier, means for pic. 12B shows exemplary cardholder transaction infor- 

combining information about the selected item and the mation - 

merchant identifier with cardholder information including a 20 cir ' - . , ^ , 

. . . & , FIG. 12C shows exemplary card company transaction 
cardholder identifier, wherein a request to pay is created, and information- 
means for transmitting the request to pay to the financial ' 

institution shows exemplary card company transaction 

* « . t f . . i j information when using a third party shipper; 

Another embodiment of the present invention includes a & r ' rr 

computer software product for use by a purchasing proces- 25 FIG - 13 shows an exemplary CardFort purchase log of 

sor operated by a cardholder. The computer software product transactions made using the financial transaction system in 

can be used to conduct a financial transaction between the accordance with the present invention; 

cardholder and a merchant, wherein the cardholder makes a FIG. 14 shows an exemplary electronic shopping cart 

purchase from the merchant using credit established at a wherein a cardholder may enter goods for purchase from a 

financial institution. The computer software product 30 merchant in accordance with the invention; and 

includes a medium readable by the purchasing processor and FIG. 15 shows a financial transaction system for making 

having stored thereon: a first sequence of instructions which, a purchase that includes a third party shipper. 

when executed by said purchasing processor, causes said 

purchasing processor to receive information about the pur- DESCRIPTION OF THE SPECIFIC 

chase and a merchant identifier; and a second sequence of 35 EMBODIMENTS 

instructions which, when executed by said purchasing r „ . , , - . , 

processor, causes said purchasing processor to transmit the 11,6 P resent ' nve ( ?' 10n ' nc " de ^ a fi , nanc ' al «™««*>°n 

information about the purchase, the merchant identifier and s y s,em 0*™**" CardFort ) that solves the problem of 

a cardholder identifier to the financial institution. for «>^umer credit card information transmuted 

, „. „ , . . , . , 40 over data networks, like the Internet. For convenience, 

Another embodiment of the present invention uses a third refcrenccs t0 tne |nternet are ^ herein> bul embodiments 

party shipper to ship items from a merchant to a cardholder. of Mc mveDlioo arc ^ ually appUcab i e t0 any tvpe of data 

The cardholder s card company provides notification to the nelwork ^ financja , Uansaction s tem revei5es ^ 

merchant that payment for the purchase has been made and £ess wim d t0 cafd transactions conducted over the 

that a particular third party shipper will be used to ship the , n ^ ^ credit card informalion ^ never lransmitted 

purchase to the cardholder. The card company also provides om , he , mernet aod , hus never outside , he possession of 

information to the third party shipper about the merchant , he cardholder ^ financial lransaclion svstem * suila bl e 

and the purchase including a cardholder address. The ship- fof ^ ^ ^ and wjth cuf sin(x embodi . 

per dentines the purchase to the merchant who then pro- meQts of , he tem a „ ow finandal institulions t0 effectuat e 

vides the purchased items to the shipper, IT* shipper then cu exch based Qn exjs(i excn ra(es 

ships the items to the cardholder at the cardholder address. ™;„ . . . .. , . . r . 

During the transaction, the merchant is not provided with the „ ^ following is a description of vanous elements of the 

identity of the cardholder or the cardholder shipping CardFort s y stem mcluded m the P resent inventl0n - 

address, thereby further protecting cardholder information. ar lcipan 

The participants in the CardFort system are the card 

BRIEF DESCRIPTION OF THE DRAWINGS 55 company, the cardholder and the merchant. The card com- 

™^ i , . t . . j A . pany is at the center of the CardFort system. The card 

FIG. 1 shows how a typical credit card transaction is r J ... . v i .1. 

. t . • y v company provides credit to the cardholder. For example, the 

conducted over the Internet; / u j-, j u 1 j-. 

. t f . , „ . t card company may be a credit card company, a bank, a credit 

FIG. 2 shows a diagram of a financial transaction system union> or other finandal institution . The crcdit prov idcd to 

m accordance with the present invention; 6Q lhe cardholder can be derived from any type of account> such 

FIG. 3 shows a method of operating the financial trans- as a credit card account, debit card account, a bank account, 

action of FIG. 2; savings account, checking account or brokerage account. 

FIG. 4 shows a diagram of a financial transaction system How credit is provided to the cardholder and the type of 

for paying merchant invoices in accordance with the present account the credit is based on is not essential to the present 

invention; 65 invention. Therefore, virtually any type of financial inslitu- 

FIG. 5 shows a method of operating the financial trans- tion can provide credit to the cardholder based on any type 

action system of FIG. 4; of account without affecting the operation of embodiments 
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of the present invention. As a matter of convenience, the 
credit provider will be referred to hereinafter as the card 
company and the person or entity receiving the credit will be 
referred to hereinafter as the cardholder. 

The cardholder establishes an account with the card 5 
company to obtain credit which may be use to make finan- 
cial transactions, such as when purchasing goods or paying 
invoices. The account established by the cardholder has 
associated confidential personal information, such as an 
account number and credit limit. The CardFort system ^ Q 
operates to eliminate the transmission of such confidential 
information outside the control of the cardholder. 

The merchant participates in the CardFort system by 
providing information about items to be purchased and by 
agreeing to be paid by the card company on behalf of the 
cardholder. 35 
Cardholder Registration 

A cardholder may register with the CardFort system by 
contacting the card company and requesting that one or 
more of the cardholder's accounts be available for use in the 
CardFort system. During cardholder registration, the card- 20 
holder receives CardFort software to install on the cardhold- 
er's computer. The software contains code that can be 
recognized by a registered merchant's website to allow a 
CardFort purchase. The software contains a changeable user 
password, a cardholder CardFort ID, a CardFort "Sales Log" 25 
database, dialing software, instructions, off-line catalog 
sites, and any miscellaneous promotions or data. The card- 
holder loads the software on his or her computer and follows 
step by step instructions culminating in clicking on a "Reg- 
ister Now" button. The software then dials the card compa- 30 
ny's toll free number, using the computer's modem, so that 
a registration process may be conducted. The cardholder's 
user ID and password is checked against the card company's 
records. At registration, a different password may be chosen. 
Multiple user IDs and passwords can be assigned to the same 35 
card number. An Order Verification Reply Target (0 VRT) is 
provided by the cardholder, so that the card company can 
notify the cardholder of order confirmations or other infor- 
mation. If the card company chooses to, it can track the 
marketing effort that led to the registration. It is also possible 40 
for the cardholder to register by voice over the telephone, 
fax or mail, however, installing the computer software 
allows the cardholder to use the CardFort system when 
making purchases over data networks, like the Internet. 
Merchant Registration 45 

A merchant may register with the card company to use the 
CardFort system. During merchant registration, the mer- 
chant becomes authorized to accept payment utilizing the 
card company's instrument. For example, the card company 
and merchant may agree to use an Automatic Clearing 50 
House (ACH) to allow bank to bank transmission of funds 
to pay for merchant goods. Thus, a merchant invoice may be 
satisfied when the card company transfers funds to the ACH 
and then notifies the merchant of the transfer. 

The merchant also registers as a CardFort website. As a 55 
CardFort website, the merchant receives computer software 
for its website that may contain brand logos, etc. and is 
capable of recognizing consumers browsing its website 
using the CardFort software. Optionally, a CardFort data- 
base may be provided to the merchant to receive non- 60 
Internet orders from consumers using off-line catalogs. A 
unique CardFort merchant identifier (ID) is issued and 
contained within the computer software given to the mer- 
chant. 

Order Verification Reply Target (OVRT) 65 

lliis is the preferred method and address for the card- 
holder to be notified that the transaction is complete, or if 



not, what if any problems exists. The notification can be an- 
automated reply via email, fax, a real time protocol during 
the same connection or voice message. The merchant may 
also provide an OVRT to the card company to receive 
information relating to cardholder purchases. 
Shipping Addresses 

During the cardholder registration, a shipping address for 
the cardholder is provided. The shipping address indicates 
where items that are purchased by the cardholder are to be 
shipped. This can be different from the cardholder's billing 
address. The billing address indicates where the card com- 
pany should send bills relating to the cardholder's credit 
account. In current types of financial transactions, the billing 
address is used as a part of the validation process, so that the 
merchant is exposed to a lack of support by the card 
company if a product is shipped to a different address. The 
CardFort allows, by use of the password and User ID, one 
or more alternative addresses to be used for specific pur- 
chases. This overcomes the problem of having a billing 
address that is different from the shipping address. For 
example, a RO. Box may be used, or some other temporary 
address, so that for instance, a cardholder may purchase 
airline tickets while traveling or when making a purchase to 
send to another address as a gift. 
CardFort Database 

A history of all CardFort purchases is maintained in a 
CardFort database maintained on the cardholder's computer. 
This allows cardholders the convenience of determining 
information about what has been purchased, vender, price, 
etc. Also, the data is in a format (i.e. tab or comma separated 
data) that may be exportable to record keeping software such 
as Quicken, Excel, FileMaker Pro or any program that 
accepts data is such a format. 
CardFort Software 

The cardholders and merchants register to obtain a Card- 
Fort ID and password. The CardFort software installed on 
the cardholder's computer works in conjunction with well 
known browser programs to allow the cardholder to browse 
the Internet and make purchases using the CardFort system. 
The following is at least a part of the information that may 
be part of the installed software: 

Plugins covering all the operating systems and browsers; 
CardFort registration software; 

CardFort database for logging purchases for the cardholder's 
use. The CardFort database also serves as the launch pad 
for data to the card company; 

Instructions for registration; 

Dialing string software for initial registration to direct toll 
free line; 

Offline website/catalogs featuring card company merchants; 
Credit card application for the card company; 
Applications to register with shipping companies; and 
A browsers) which is configured to dial direct any of the 
selected merchants via a toll free offline number. The 
cardholder can make buying selections off line and uti- 
lizing all of the benefits of CardFort to burst their selec- 
tion to the merchant's CardFort data base. 
Off-Line Catalog/Website 

Purchases may be made by the cardholders using off-line 
catalog/websites which may be provided as part of the 
CardFort software. The catalog/websites may be provided in 
electronic form and can be functional copies of merchant 
websites. The catalogs serve as a stand alone method for the 
card company and/or merchants to open another sales chan- 
nel. Some of the benefits of the off-line catalog or website 
are: 

The off-line Website acts as a digital catalog; 
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Off-line CardFort shopping stops "wandering" shoppers by 
allowing them to view only selected merchants; 

Staff personal required to answer telephone calls from 
conventional shoppers is reduced or eliminated, thus 
eliminating expense and shortening phone time; 5 

Merchants save money by producing a catalog once as a 
website; 

Production costs compared to paper catalogs is minimized; 

Shipping and mailing costs for catalogs are minimized; 

Updates are as fast as updates to the website; no 

Users with no Internet connection or who choose not to use 
the Internet can still buy products from the catalog; and 

The off-line catalogs open another sales channel for mer- 
chants. 

Embodiments of the CardFort System 15 

FIG. 2 shows a financial transaction system 200 
(CardFort) constructed in accordance with the present inven- 
tion. As part of the CardFort system, a credit card company 
202 (or other credit provider) issues software to a cardholder 
204 that is used on the cardholder's computer to implement 20 
features of the CardFort system, thus allowing the card- 
holder to conduct financial transactions over the Internet. 
The card company 202 also authorizes a subscribed mer- 
chant 206 to utilize the CardFort system and issues software 
to the merchant for use in conjunction with the merchant's 25 
website. The merchant agrees to accept payment from the 
card company via an ACH 222, which may perform bank to 
bank transfers. Once the software is installed on both the 
cardholder's and merchant's computers, a financial transac- 
tion in accordance with the present invention may be con- 30 
ducted. 

FIG. 3 shows a method 300 of conducting a financial 
transaction using the financial transaction system of FIG. 2. 
Using the method 300, secure financial transactions may 
occur between the cardholder 204, merchant 206, and card 35 
company 202. 

At block 302, the cardholder browses the Internet using a 
browser program, however, specific details of the browser 
program are not relevant to the present invention. In one 
embodiment, the CardFort software operates as a plug-in in 40 
the cardholder's browser program. 

At block 304, the cardholder enters the merchant's 
website, which is also running the CardFort software. The 
merchant's website recognizes the CardFort plugin included 
in the cardholder's browser software, and thus knows that 45 
the cardholder is a member of the CardFort system. For 
example, in one embodiment, the plugin installed on the 
cardholder's computer may send special codes upon enter- 
ing the merchant's website. These codes are interpreted by 
the CardFort software installed on the merchant's system to 50 
determine that the cardholder is registered with the CardFort 
system. In another embodiment, the merchant's system 
transmits special codes to the cardholder's computer, which 
can be interpreted at the cardholder's computer. A response 
is generated from the cardholder's computer to the mer- 55 
chant's system, which results in both computer system's 
acknowledging membership in the CardFort system. 

At block 306, the cardholder selects one or more products 
or services for purchase from the merchant's website. This 
is shown at path 208 in FIG. 2. For example, the website 60 
may have a virtual shopping cart that the cardholder places 
selections into. At some point, the cardholder desires to 
purchase the items in the shopping cart, and clicks on a 
"button" which may read, "pay by CardFort." This is shown 
at path 210. 65 

At block 308, after the cardholder clicks the "pay by 
CardFort" button, which is signaled to the merchant's 



computer, the merchant's computer saves the cardholder's 
order in a merchant data base. The merchant's computer 
then creates a purchase order containing the merchant's 
CardFort ID, a unique order number for the purchase, a 
dollar amount for the purchase, and any other desired data 
such as the merchant's email address, URL, etc. The pur- 
chase order is transmitted to the cardholder's computer, as 
shown at path 212, and stored in a CardFort database on the 
cardholder's computer. In essence, the purchase order acts as 
the merchant's offer to sell the selected items to the card- 
holder. 

At block 310, the cardholder's browser "tickles" the 
merchant site to keep the Internet connection active. In the 
meantime, the cardholder's browser transmits a request to 
pay (RTP) to the card company's system as shown at path 
214. The RTP includes the purchase order data from the 
merchant and the cardholder's unique CardFort ID and 
password. 

At blocks 312 and 314, the request to pay (RTP) and the 
purchase order enters the card company's CardFort system. 
The card company's CardFort software performs two tests. 
The first test, at block 312, determines whether the card- 
holder is allowed to make the requested purchase. For 
example, it is determined whether the cardholder has enough 
credit available to pay for the selected items. The second 
lest, at block 314, determines whether the merchant is 
allowed to participate in this transaction. For example, is the 
merchant a registered CardFort merchant in good standing. 

At block 316, if either test fails, the system replies to the 
predetermined OVRT addresses with an appropriate mes- 
sage for both the merchant and the cardholder. For example, 
one message may go to the cardholder that says that there is 
not enough credit available to make the requested purchase. 
A second message may go to the merchant that says that the 
cardholder is unable to complete the transaction. The mer- 
chant may also receive a message indicating that the trans- 
action was terminated since the merchant is not a CardFort 
member. The merchant's OVRT may be provided during 
merchant registration or included in the purchase order 
information sent to the card company. Once the messages 
are sent, the transaction is terminated as shown at block 318. 

At block 320, if both tests at blocks 312 and 314 pass, the 
card company system replies to the predetermined OVRT 
addresses with an appropriate message to both the card- 
holder and the merchant. The message to the cardholder, 
shown at path 216 may be an order confirmation number or 
other indication that the order is to be placed. The message 
to the merchant includes a unique order number and a 
pre-registered shipping address or an authorized alternate 
shipping address, as shown at path 218. The card company 
also notifies the merchant that payment has been made to the 
ACH used to transfer funds between the card company and 
the merchant. 

At block 322, the merchant matches the order information 
contained in the received OVRT with the order information 
contain in the merchant database. If the information 
matches, the merchant ships the order to the address speci- 
fied. 

At block 324, the card company's system collects pay- 
ment from cardholder and forwards payment to the merchant 
via a settlement transfer to the ACH 222, as shown at path 
220. Once the settlement transfer is made, the transaction is 
complete as shown at block 326. 

As a result of performing a financial transaction in accor- 
dance with the method 300, the cardholder's credit card 
number or other personal information is never transmitted 
over the computer network. This prevents anyone from 
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stealing the information. An additional level of security is 
provided since the merchant never has access to the credit 
card number or other personal information. Therefore, cor- 
ruption or lack of security at the merchant's site will have no 
effect on the security of the cardholder's personal informa- 5 
tion. 

The transfer of funds from the card company to the 
merchant may occur in several ways. In the above 
embodiment, the transfer occurred using an ACH. Since the 
transfer of funds is secondary to the present invention, it is 3Q 
possible to transfer funds in other ways without deviating 
from the scope of the present invention. For example, by 
wiring funds directly to a merchant's account. 
Invoice Paying System 

In another embodiment of the present invention, an 
invoice paying system is provided, wherein a cardholder can 15 
make payments to merchants and/or service providers and/or 
other CardFort cardholders registered with the CardFort 
system. 

FIG. 4 shows an invoice paying system 400 (or bill paying 
system) for paying invoices for goods or services in accor- 20 
dance with the present invention. The system 400 operates 
to allow a cardholder 402 to pay an invoice from a merchant 
404 via a card company 406. 

FIG. 5 shows a method 500 for conducting a financial 
transaction for use with the invoice paying system of FIG. 25 
4. It will be assumed that the merchant and cardholder are 
registered with the CardFort system. 

At block 502, the cardholder receives an invoice for goods 
and/or services from the merchant. The invoice may be 
received via electronic means, such as email, or as a deliv- 30 
ered hardcopy. The invoice contains the merchant's Card- 
Fort ID number along with other relevant billing informa- 
tion. This is shown at path 408. 

At block 504, the cardholder enters the merchant's Card- 
Fort ID information and the billing information into his or 35 
her own computer system, which has the CardFort software 
installed. 

At block 506, the cardholder transmits all the information 
to the card company along with an RTP as shown at path 
410. 40 

At block 508, the card company verifies that the card- 
holder has the available credit to pay the merchant invoice. 

At block 510, the card company verifies that the merchant 
is registered with the CardFort system and is eligible to 
receive payments made through the system. 45 

At block 512, if the checks performed at blocks 508 and 
510 of the cardholder or the merchant fail, then a message 
is sent to the cardholder indicating that the invoice cannot be 
paid by the CardFort system. The transaction is then termi- 
nated as shown at block 514. A message need not be sent to 50 
the merchant, since the merchant may not even be aware that 
the cardholder is attempting to pay the invoice via the 
CardFort system. 

At block 516, if the checks at blocks 508 and 510 pass, the 
card company notifies the merchant that payment has been 55 
made on behalf of the cardholder for the invoice amount. 
This is shown at path 412. The card company transfers funds 
to the ACH 416 agreed to by the merchant and the card 
company, as shown at 418. 

At block 518, the card company sends a confirmation to 60 
the cardholder indicating that the merchant has been paid, as 
shown at path 414. 

At block 520, the transaction is completed and the card- 
holder can record in a payment log that the invoice has been 
paid. The merchant sends the purchased items to the card- 65 
holder which may include an account statement for the 
cardholder's records. 
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In business situations, the invoice paying system allows 
the consumer to make repeat orders or orders as needed, 
rather than having to cancel a standing automatic recurring 
system order. Professional services that don't have a web 
site, but wish to take credit card payments, can do so using 
the invoice paying system included in the present invention. 
For example, if the cardholder obtains the service provider's 
CardFort ID number and invoice information from a bill 
mailed to the cardholder. The cardholder can still arrange for 
payments to be made via the CardFort system with notifi- 
cation sent to the merchant via standard telephone, mail or 
fax systems. 

Off-Line Catalog/Website Purchases 

In one embodiment of the present invention a financial 
transaction system is provided for purchasing goods and 
service from catalogs published by merchants. The catalogs 
may be in the form of hardcopy or in the form of electroni- 
cally downloaded merchant catalogs or web pages. Thus, a 
purchaser can view the catalog information in an off-line 
mode, i.e. when not connected to a merchant's website, and 
purchase selected goods or services. When downloaded as 
web pages, the catalogs may be fully functional and operate 
in the same manner as if the cardholder was connected 
on-line to the merchant's website. 

FIG. 6 shows a financial transaction system 600 for 
purchasing goods and services off-line. A merchant 602 
provides catalog information 601 about available goods or 
services to a cardholder 604 (or purchaser). The cardholder 
604 make purchases from the catalog 601 using the CardFort 
system provided by a card company 606. An ACH 622 may 
be used to make bank to bank transfers allowing the card 
company to transfer funds to the merchant on behalf of the 
cardholder. 

FIG. 7 shows a method 700 for conducting a financial 
transaction using the financial transaction system of FIG. 6. 

At block 702, the cardholder 604 receives a catalog 601 
from the merchant 602, as shown at path 608. The card- 
holder may obtain the catalog in several ways. For example, 
the merchant may send a hardcopy catalog to the cardholder 
via regular mail or other mail delivery or facsimile service. 
The merchant may also transmit a softcopy of the catalog to 
the cardholder's computer via email or other electronic 
transmission means. It is even possible for the cardholder to 
connect to the merchant's website and selectably download 
the catalog from the merchant's website to the cardholder's 
computer for later viewing. The catalog may also be an 
off-line functional version of the merchant's website. 

The catalog includes information identifying goods and/ 
or services offered by the merchant. The information also 
includes prices associated with each good or service and 
related shipping services available and costs. The catalog 
may also include the merchant's CardFort ID and any other 
CardFort merchant profile information. 

At block 704, the cardholder reviews the merchants 
catalog off-line. For example, the cardholder may read the 
hardcopy of the catalog when away from his or her 
computer, or may view the electronic version of the catalog 
on his or her computer when not connected to the merchant's 
on-line system. Assuming an electronic off-line catalog is 
being viewed, the cardholder may select items for purchase 
and click on a "buy" button to begin the purchase process. 
Assuming a hardcopy catalog is being viewed, the card- 
holder may select items for purchase and enter correspond- 
ing item identification information, the merchant's CardFort 
ID, a phone number to contact the merchant, and any other 
related information into the cardholder's CardFort software. 

At block 706, after the selections are made and the "buy" 
button is clicked on, the cardholder's computer activates a 
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dialing string which dials a phone number designated by the 
merchant to take digital orders. This is shown at path 610. 
The merchant's CardForl or other software answers the call 
to receive the purchase data from the cardholder's computer, 
which may be in the form of delimited text and stores it in 5 
the merchant's database. Optionally, the merchant's com- 
puter system will check for inventory levels and/or price 
changes. If items are out of stock or there has been a price 
change, the merchant's software will reply to the cardhold- 
er's computer to give the cardholder the option to revise the 
order or to proceed. The merchant will have the option to 
terminate the call and prompt the cardholder to resubmit the 
order when the changes have been made or to keep the 
connection while the cardholder revises the order. 

In another embodiment, when the "buy" button is clicked 
on, the cardholder's computer is directed to the merchant's 15 
website on the data network. After the data network con- 
nection is established, information exchanged between the 
merchant and the cardholder is done via the data network. 

At block 708, the merchant's computer then creates a 
purchase order containing the merchant's CardFort ID, a 20 
unique order number for the purchase, a dollar amount for 
the purchase, and any other desired data such as the mer- 
chant's email address, URL, etc. The purchase order is 
transmitted to the cardholder's computer, as shown at path 
612, and stored in a CardFort database on the cardholder's 25 
computer. 

At block 710, the cardholder's computer transmits a 
request to pay (RTP) to the card company's system as shown 
at path 614. The RTP may be transmitted over a direct 
telephone connection to the card company's system. The 30 
RTP includes the purchase order data from the merchant and 
the cardholder's unique CardFort ID and password. 
Alternatively, the request to pay may also include other 
information, such as cardholder survey information, wherein 
the cardholder recommends other merchants that should be 35 
part of the CardFort system. 

At block 712, the card company's system checks to see if 
the received RTP is from a registered CardFort member. The 
card company's system also reviews the information regard- 
ing the requested purchase and determines if the cardholder 40 
has sufficient funds or credit to cover the cost of the 
requested items. 

At block 714, the card company's system checks to see if 
the merchant ID belongs to a registered CardFort merchant. 
The card company's system may perform other checks on 45 
the merchant, such as checking customer service ratings, etc. 

At block 716, if either the cardholder or the merchant fail 
the checks performed in blocks 712 and 714, then a termi- 
nation message is sent from the card company to the 
cardholder. The termination message indicates to the card- 50 
holder why the requested purchase was rejected. At block 
718, after the termination message is sent, the attempted 
transaction is terminated. 

At block 720, if both checks in blocks 712 and 714 pass, 
then the card company's system creates a purchase order to 55 
transmit to the merchant as shown at 616. The purchase 
order contains information about the items to be purchased, 
shipping information and payment notification. At the same 
time, the card company transfers payment to the merchant 
via the ACM 620, as shown at path 618. 60 

At block 722, an order confirmation sent from the card 
company informs the cardholder that the order has been 
placed, as shown at path 620. 

At block 724, the merchant ships the requested items to 
the cardholder at the address specified in the purchase order. 65 
At block 726, the cardholder receives the items requested 
and the transaction is completed. 
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Purchases via Card Company Portal 

In one embodiment of the present invention a financial 
transaction system is provided for purchasing goods and 
services over a data network using a portal provided by a 
financial institution. The portal is a location on the data 
network that can be accessed by the cardholder. For 
example, a cardholder may have a credit account with a 
financial institution. The cardholder logs onto a portal oper- 
ated by the financial institution. The portal provides the 
cardholder the capability to browse the product offerings of 
selected merchants associated with the financial institution 
and to purchase items from them. When purchases are made, 
the merchant and the financial institution negotiate the 
payment and the items are ship directly to the cardholder. 
Thus, a secure transaction can occur with minimal card- 
holder involvement and without transmitting the cardhold- 
er's card number over the data network. 

FIG. 8 shows a financial transaction system 800 for 
purchasing goods and services via a financial institution 
portal in accordance with the present invention. A card- 
holder 802 logs into the portal of a financial institution 804 
which provides links to one or more merchants. A merchant 
806 provides information about available goods or services 
offered to a cardholder 802 via the portal. When the card- 
holder desires to make purchases from the merchant, the 
financial institution and the merchant complete a financial 
transaction to purchase the items. The merchant then ships 
the goods to the cardholder. Since the merchant's are linked 
to the cardholder through the portal, the financial institution 
knows all the merchant IDs and can thus assure that all the 
linked merchants are registered with the CardFort system 
and are in good standing. If not, a merchant may be removed 
from the financial institution's portal. 

FIG. 9 shows a method 900 for conducting a financial 
transaction using the financial transaction system of FIG. 8. 

At block 902, the cardholder logs into the portal provided 
by the financial institution. This is shown at path 808. At 
block 904, the cardholder selects one of the merchants 
associated (linked) with the portal and logs into the selected 
merchant website, as shown at path 810. 

At block 906, the merchant transmits product information 
to the portal as shown at path 812. At block 908, the product 
information from the merchant is forwarded to the card- 
holder as shown at path 814. 

At block 910, the cardholder selects an item for purchase 
from the merchant's product information. The cardholder 
sends a Selection as shown at 815 and an RTP to the portal 
as shown at path 816. At block 912, the portal forwards the 
Selection to the merchant which triggers the order to be 
saved as shown at path 818. At block 914, the merchant 
receives the "Buy" signal and transmits the order 
information, such as order number and amount, to the protal 
website as shown at path 820. 

At block 916, the financial institution receives the order 
information and determines if the cardholder has enough 
credit available to cover the cost of the purchase. The 
financial institution may make other checks at this time, for 
example, whether the cardholder is eligible to purchase 
products from this particular vendor. 

At block 918, if the cardholder does not have the credit or 
resources available to pay for the selected item, then a 
termination message is sent to the cardholder, and at block 
920, the transaction is terminated. 

At block 922, if the financial institution determines that 
the cardholder has credit available to purchase the selected 
item, then a notification is sent to the merchant informing the 
merchant that payment has been made and that the item 
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should be shipped to the cardholder at a specified cardholder 
address, as shown at path 822. A transfer of funds to the 
merchant is made by the card company via an ACH 830, as 
shown at path 832. 

At block 924, a confirmation of the purchase is sent to the 5 
cardholder as shown at path 824, indicating that the purchase 
has been completed. At block 926, the merchant ships the 
selected item to the cardholder as shown at path 826. At 
block 928, the transaction is completed. 
Exemplary Apparatus 30 

FIG. 10 shows a computer device 1000 suitable for use io 
embodiments of the financial transaction system in accor- 
dance with the present invention. Computer device 1000 
includes display 1002 having display screen 1004. Cabinet 
1006 houses standard computer components (not shown) is 
such as a disk drive, CDROM drive, display adapter, net- 
work card, random access memory (RAM), central process- 
ing unit (CPU), and other components, subsystems and 
devices. User input devices such as a mouse 1008 having 
buttons 1010, and a keyboard 1012 are shown. Other user 20 
input devices such as a trackball, touch -screen, digitizing 
tablet, etc. can be used. In general, the computer device 1000 
is illustrative of one type of computer system, such as a 
desktop computer, suitable for use with the present inven- 
tion. Computers can be configured with many different 25 
hardware components and can be made in many dimensions 
and styles (e.g., laptop, palmtop, server, workstation, 
mainframe). Thus, any hardware platform suitable for per- 
forming the processing described herein is suitable for use 
with the present invention. 30 

FIG. 11 illustrates subsystems that might typically be 
found in a computer device such as computer device 1000. 
Subsystems within box 1006 are directly interfaced to an 
internal bus 1110. Such subsystems typically are contained 
within the computer system, such as within the cabinet 1006 35 
of FIG. 10. Subsystems include input/output (I/O) controller 
1112, System Random Access Memory (RAM) 1114, Cen- 
tral Processing Unit (CPU) 1116, Display Adapter 1118, 
Serial Port 1120, Fixed Disk 1122 and Network Interface 
Adapter 1124. The use of the bus 1110 allows each of the 40 
subsystems to transfer data among the subsystems and, most 
importantly, with the CPU 1116. External devices can com- 
municate with the CPU or other subsystems via the bus 1110 
by interfacing with a subsystem on the bus. Monitor 1126 
connects to the bus through Display Adapter 1118. A relative 45 
pointing device (RPD) 1128 such as a mouse connects 
through Serial Port 1120. Some devices such as keyboard 
1130 can communicate with the CPU 1116 by direct means 
without using the main data bus as, for example, via an 
interrupt controller and associated registers (not shown). 50 

As with the external physical configuration shown in FIG. 
10, many subsystem configurations are possible. FIG. 11 is 
illustrative of one suitable configuration. Subsystems, com- 
ponents or devices other than those shown in FIG. 11 can be 
added. A suitable computer system can be achieved without 55 
using all of the subsystems shown in FIG. 11. Other sub- 
systems such as a CDROM drive, graphics accelerator, etc. 
can be included in the configuration without affecting the 
performance of the system of the present invention. 
Exemplary Data Formats in the CardFort System 60 

FIGS. 12A-12D show exemplary data formats which may 
be used during transactions described in the above embodi- 
ments. 

FIG. 12A shows an exemplary data format 1200 for 
information transmitted from a merchant to a cardholder 65 
during operation of embodiments of the present invention. 
The data format 1200 includes a merchant ID 1202, an order 



number 1204, a purchase amount 1206, a transaction data 
1208 and a merchant OVTR 1210. Other information rela- 
tive to the financial transaction may be included, however, 
the data format 1200 is intended to be an exemplary list and 
not an exhaustive list of all the possible data that may be 
transmitted from the merchant to the cardholder during 
operation of the financial transaction system included in the 
present invention. 

FIG. 12 B shows an exemplary data format 1220 for 
information transmitted from a cardholder to a card com- 
pany during operation of embodiments of the present inven- 
tion. The data format 1220 may includes all or a portion of 
the data included in the data format 1220. The data format 
1220 also includes a CardFort cardholder ID 1222 and a 
cardholder OVTR 1224. Other information relative to the 
financial transaction may be included, however, the data 
format 1220 is intended to be an exemplary list and not an 
exhaustive list of all the possible data that may be transmit- 
ted from the cardholder to the card company during opera- 
tion of the financial transaction system included in the 
present invention. 

FIG. 12 C shows an exemplary data format 1230 for 
information transmitted from a card company to a merchant 
during operation of embodiments of the present invention. 
The data format 1230 may include the order number 1204, 
the purchase amount 1206 and the transaction date 1208. 
Additional information such as a shipping name 1232, a 
shipping address 1234, a shipping state 1236, a shipping 
state 1238 and a shipping zip code 1240 may also be 
included. Other information relative to the financial trans- 
action may be included, however, the data format 1230 is 
intended to be an exemplary list and not an exhaustive list 
of all the possible data that may be transmitted from the card 
company to the merchant during operation of the financial 
transaction system included in the present invention. 

FIG. 12D shows an exemplary data format 1250 for 
information transmitted from a card company to a merchant 
during operation of embodiments of the present invention. 
The data format 1250 may include the order number 1204, 
the purchase amount 1206 and the transaction date 1208. 
Information 1243, which relative to the cardholder's ship- 
ping information, can be omitted so that such information 
given to the merchant only identifies the purchase that has 
been paid for. The data format 1250 may also include a 
shipper identifier 1241, so that the merchant is notified of a 
third party shipper that will handle shipping the purchase to 
the cardholder. The cardholder's shipping information may 
be given to the third party shipper and may be keep 
confidential from the merchant. Other information relative 
to the financial transaction may be included, however, the 
data format 1250 is intended to be an exemplary list and not 
an exhaustive list of all the possible data that may be 
transmitted from the card company to the merchant during 
operation of the financial transaction system included in the 
present invention. 

FIG. 13 shows an exemplary CardFort purchase log 1300 
that may be included with the CardFort system and located 
at the cardholder's computer system. The purchase log 
includes a transaction date 1302, a merchant (company 
name) 1304 and a purchase amount 1306. The purchase log 
1300 may also include a merchant URL 1308 or merchant 
email address 1310, which can be part of the merchant's 
OVRT. A transaction number 1312 may also be included in 
the purchase log. The transaction number 1312 being rela- 
tive to a card company transaction system, so that the 
cardholder may reference a particular transaction by the card 
company transaction number. 
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Other information relative to financial transactions may 
be included in the purchase log, however, the purchase log 
1300 is intended to be an exemplary list and not an exhaus- 
tive list of all the possible data that may be included. A 
similar purchase log may be found at the merchant or card 5 
company site. Thus, all parties to a particular transaction 
may maintain log information, and thereby store a history of 
financial transaction information. 

FIG. 14 shows an exemplary electronic shopping cart 
1400 wherein a cardholder may enter goods for purchase no 
from a merchant. The electronic shopping cart 1400 can be 
used in both on-line and off-line operating modes. For 
example, when a cardholder is connected to a merchant's 
web site, the merchant information, as shown at 1402, is 
automatically inserted. If an off-line catalog electronic cata- is 
log from the merchant is used, the merchant information 
1402 may also be automatically inserted. However, if a 
hardcopy of a merchant catalog is being used, the cardholder 
manually enters the merchant information 1402 into the 
electronic shopping cart. 20 

As each selection is entered, item information, shown at 
1404, is entered into the electronic shopping cart. A total is 
provided at 1406. When the cardholder has completed 
making item selections, a buy button 1408, may be clicked 
on to start the financial transaction as provided for in 25 
embodiments of the present invention. Therefore, the elec- 
tronic shopping cart can be used in both on-line and off-line 
applications to select item for purchase from a merchant and 
to activate a financial transaction in accordance with the 
present invention. 30 

FIG. 15 shows a financial transaction system 1500 for 
making a purchase using a third party shipper. In the system 
1500, the cardholder 1502 receives purchase information 
1504 from a merchant 1506. The cardholder 1502 sends a 
RTP 1508 to card company 1510, which sends payment 35 
1512 via ACH 1516, and payment notification 1514 to the 
merchant 1506. The transaction to this point is similar to 
transactions described in other embodiments above. 

Also included in the system 1500 is a third party shipper 
1518. The third parly shipper 1518 provides an additional 40 
level of security, by protecting the identity and address of the 
cardholder 1502 from the merchant 1506. During operation 
of the system 1500, the card company does not included 
cardholder shipping information in the payment notification 
1514. Instead, the card company sends the shipping infor- 45 
mation along with information identifying the purchase and 
the merchant (as shown at 1522) to the shipper 1518. In the 
payment notification 1514, the card company informs the 
merchant 1506 that the shipper 1518 will be used to ship 
purchased items. As a result, the merchant 1506 is provided 50 
notification that payment for a particular purchase has been 
made, but is not notified where the purchase is to be shipped 
or who the receiver will be. Thus, a further level of security 
for the cardholder information is established. 

The shipper 1518 and the merchant 1506 exchange infor- 55 
mation 1520 wherein the shipper identifies the cardholder's 
purchase and the merchant provides the items to be shipped. 
However, the merchant does not know the cardholder's 
address and the shipper does not provide this information to 
the merchant. The shipper receives the items from the 60 
merchant and ships them to the cardholder address (as 
shown at 1524) provided in the shipping information from 
the card company. As a result, the cardholder's shipping 
address is protected from the merchant in addition to the 
cardholders credit card number. After the card company 65 
sends the payment notification, a confirmation 1526 is sent 
to the cardholder 1502. 



In another embodiment of the present invention, financial 
transactions can be made between two or more CardFort 
cardholders. For example, transactions involving personal 
items such as used automobiles, furniture or jewelry may be 
transacted using the CardFort system. In such a transaction, 
a first registered CardFort cardholder (seller) provides his or 
her CardFort identifier to a second registered CardFort 
cardholder (buyer). The buyer cardholder then sends a RTP 
to the card company, which in turns, credits the seller's 
account and sends a payment notification to the seller. A 
confirmation is then sent to the buyer. The Seller then 
provides the automobile to the buyer. In this transaction the 
CardFort system protects the buyer's account number from 
the seller and thus functions to provide a secure transaction 
mechanism that can facilitate credit based transactions or 
replace the use of personal checks or cash. 
Additional Benefits of the CardFort System 
"E Wallets" Eliminated 

E wallets are software systems which store the cardhold- 
er's card number to avoid the repeated effort of filling out the 
customer data for each purchase. Some E wallets reside on 
the cardholder's computer while some are held on a remote 
server. These devices actually increase the vulnerability of 
the card number by holding both the card number and the 
owner's details in the same repository (wherever that may 
be) and in the case of server based E wallets, the number 
travels to and is known by a third party. The various 
embodiments of the present invention eliminate the use of E 
wallets, since the cardholder's card number is no longer 
transmitted over a data network. 
Affinity and Coupon Programs 

Because the transaction is tied to the CardFort ID number, 
the card company can enroll any cardholder in specific 
affinity or reward programs. Processing the savings and 
fraud reduction provided by the CardFort system will allow 
more resources to be available for reward programs. 
Age Verification and Account limits 

If the card company chooses to it can implement an age 
verification system with the CardFort registration process. 
'I riis is a substantial benefit to merchants and cardholders. 
Merchants can sell products and services to buyers who need 
to be of a certain maximum or minimum age, by law or 
policy. Cardholders verify their age with card companies 
when they apply for a credit line and register with the 
CardFort system. Thus, the cardholder's age is associated 
with his/her CardFort user ID. As a result, purchases can be 
checked for age verification before being approved. Card- 
holders can have different user IDs assigned to their 
children, so that attempted purchases from those user IDs 
not meeting the minimum age requirements would fail. The 
same system of multiple user IDs applies to creating account 
limits for IDs assigned to children, or for example, company 
employees. 
Merchant Selection 

The card company can choose to register some merchants 
and not others based on its policies. Merchants who are 
appropriate to make "card presented at time of purchase" 
sales may not be appropriate to make network sales using the 
CardFort system. 

The present invention provides a method and apparatus 
for conducting financial transactions over a data network, 
such as the Internet. It will be apparent to those with skill in 
the art that modifications to the above methods and embodi- 
ments can occur without deviating from the scope of the 
present invention. Accordingly, the disclosures and descrip- 
tions herein are intended to be illustrative, but not limiting, 
of the scope of the invention which is set forth in the 
following claims. 
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What is claimed is: 

1. A method of performing a financial transaction allow- 
ing a cardholder to make a purchase from a merchant using 
credit established at a financial institution, the method 
comprising: 5 

transmitting a merchant offer from the merchant to the 
cardholder, wherein the merchant offer includes mer- 
chant information about the merchant and the purchase; 

transmitting at least a portion of the merchant information 
and cardholder information from the cardholder to the 10 
financial institution, wherein the financial institution 
uses the merchant information and the cardholder infor- 
mation to determine whether the merchant offer and/or 
the purchase are authorized; 

transmitting payment for the purchase from the financial 
institution to a merchant account; and 

sending a purchase request from the financial institution 
to the merchant, the purchase request including at least 
a portion of the merchant offer and a payment 20 
notification, wherein the portion of the merchant offer 
is used to match up the purchase request with the 
purchase, and the payment notification is used to indi- 
cate that payment for the purchase has been made and 
that the merchant offer has been accepted, and wherein 2 $ 
the purchase request does not contain any information 
relating to the identity of the cardholder. 

2. The method of claim 1, further comprising a step of 
confirming that the cardholder has enough credit at the 
financial institution to pay for the purchase. 30 

3. The method of claim 1, further comprising a step of 
verifying that the merchant is authorized to receive payment 
for the purchase from the financial institution. 

4. The method of claim 1, wherein the payment notifica- 
tion includes a purchase identifier and a cardholder address, 35 
and further comprises a step of shipping purchased items 
from the merchant to the cardholder address. 

5. The method of claim 1, wherein the merchant infor- 
mation includes information about the purchase and a mer- 
chant identifier. 40 

6. The method of claim 1, wherein the step of sending the 
purchase request comprise; steps of: 

sending a purchase identifier from the financial institution 

to the merchant; and 
sending shipping information from the financial institu- 45 

tion to the merchant. 

7. The method of claim 1 further comprising a step of 
selecting an item included in the purchase from a merchant 
website. 

8. The method of claim 1 further comprising a step of 50 
selecting an item included in the purchase from a merchant 
catalog. 

9. The method of claim 8 wherein the step of transmitting 
the merchant offer comprises a step of providing merchant 
information about the item and a merchant identifier in the 55 
merchant catalog. 

10. The method of claim 9 wherein the step of transmit- 
ting the merchant offer comprises a step of providing mer- 
chant information about the item and a merchant identifier in 

a hardcopy of the merchant catalog. 60 

11. The method of claim 9 wherein the step of transmitting 
the merchant offer comprises a step of providing merchant 
information about the item and a merchant identifier in an 
electronic off-line copy of the merchant catalog. 

12. A method of operating a financial institution for 65 
performing a financial transaction between a cardholder and 

a merchant, wherein the cardholder makes a purchase from 
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the merchant using credit established at the financial 
institution, the method comprising: 
receiving a request to pay the merchant from the 
cardholder, the request to pay includes information 
about the purchase, a merchant identifier and a card- 
holder identifier; 
determining whether the cardholder has sufficient credit 
established at the financial institution to make the 
purchase; and 

if it is determined that the cardholder has sufficient credit, 
transmitting funds from the financial institution to a 
merchant account to pay for the purchase; and 

sending a purchase request from the financial institution 
to the merchant, the purchase request including at least 
a portion of the request to pay and a payment notifi- 
cation indicating that payment for the purchase has 
been made; 

wherein the purchase request does not reveal the identity 
of the cardholder. 

13. A method of claim 12 further including a step of 
assigning the merchant identifier and the cardholder 
identifier, wherein the merchant and cardholder identifiers 
are stored at the financial institution and used to identify the 
merchant and the cardholder from the request to pay. 

14. The method of claim 12 further including the step of 
transmitting a confirmation to the cardholder after notifying 
the merchant that payment has been made. 

15. A method for operating a merchant business for 
performing a financial transaction between a cardholder and 
a merchant, wherein the cardholder makes a purchase from 
the merchant using credit established at a financial 
institution, the method comprising: 

transmitting to the cardholder information about items 
offered by the merchant and a merchant identifier; 

receiving a purchase request from the financial institution, 
said purchase request including a payment notification 
indicating that payment for at least one item has been 
made, wherein the purchase request does not reveal the 
identity of the cardholder; and 

delivering the at least one item to a delivery service 
thereby allowing the delivery service to deliver the at 
least one item to the cardholder at a shipping address, 
wherein the shipping address is forwarded to the deliv- 
ery service from the financial institution without 
knowledge of the merchant. 

16. The method of claim 15 wherein the step of trans- 
mitting comprises a step of providing the cardholder infor- 
mation about the items offered and the merchant identifier in 
a merchant catalog. 

17. A method for operating a cardholder computer for 
performing a financial transaction between a cardholder and 
a merchant, wherein the cardholder makes a purchase from 
the merchant using credit established at a financial 
institution, the method comprising: 

obtaining item information and a merchant identifier from 
the merchant; and 

transmitting a request to pay from the cardholder com- 
puter to the financial institution, the request to pay 
includes the item information, the merchant identifier 
and a cardholder identifier and instructs the financial 
institution to purchase a selected item for the card- 
holder from the merchant without revealing the identity 
of the cardholder. 

18. The method of claim 17 further comprising the step of 
receiving confirmation from the financial institution that the 
selected item has been paid for by the financial institution. 
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19. The method of claim 17 wherein the step of obtaining 
item information comprises a step of obtaining the item 
information and the merchant identifier from a data network. 

20. The method of claim 17 wherein the step of obtaining 
item information comprises a step of obtaining item infor- 5 
mation and the merchant identifier from an off-line elec- 
tronic catalog. 

21. The method of claim 17 wherein the step of obtaining 
item information comprises a step of obtaining item infor- 
mation and the merchant identifier from a hardcopy catalog. 3 o 

22. The method of claim 17 further comprising a step of 
recording the transaction in a cardholder purchase log. 

23. Apparatus for use by a cardholder for conducting a 
financial transaction between the cardholder and a merchant, 
wherein the cardholder makes a purchase from the merchant 1S 
using credit established at a financial institution, the appa- 
ratus comprising: 

means for selecting an item to be purchased from the 
merchant; 

means for receiving information about the selected item 20 
including a merchant identifier; 

means for combining information about the selected item 
and the merchant identifier with cardholder information 
including a cardholder identifier, wherein a request to 
pay is created; and 25 

means for transmitting the request to pay from the card- 
holder to the financial institution to instruct the finan- 
cial institution to purchase the selected item for the 
cardholder without revealing the identity of the card- 
holder. 30 

24. The apparatus of claim 23 further comprising: 
means for receiving an order confirmation; and 
means for recording information about the purchase in a 

cardholder purchase log. 

25. Apparatus for use by a merchant for conducting a 35 
financial transaction between a cardholder and the merchant, 
wherein the cardholder makes a purchase from the merchant 
using credit established at a financial institution, the appa- 
ratus comprising: 

means for transmitting to the cardholder information 
about at least one item offered for sale by the merchant 
and a merchant identifier; and 

means for receiving a purchase request from the financial 
institution, said purchase request includes a request to 45 
purchase the at least one item from the merchant and a 
payment notification indicating that payment for the at 
least one item has been made. 

26. The apparatus of claim 25 further comprising means 
for recording information about the purchase in a merchant 5Q 
purchase log. 

27. Apparatus for use by a financial institution for con- 
ducting a financial transaction between a cardholder and a 
merchant, wherein the cardholder makes a purchase from the 
merchant using credit established at the financial iastitution, 55 
the apparatus comprising: 

means for transmitting a request to pay the merchant from 
the cardholder to the financial institution, the request to 
pay includes information about the purchase, a mer- 
chant identifier and a cardholder identifier; 60 

means for determining if the cardholder has sufficient 
credit established at the financial institution to make the 
purchase; 

means for transmitting funds from the financial institution 
to a merchant account to pay for the purchase; and 65 

means for sending a purchase request from the financial 
institution to the merchant, said purchase request 
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includes a request to make the purchase from the 
merchant and includes a payment notification indicat- 
ing that payment for the purchase has been made. 

28. The apparatus of claim 27 further comprising means 
for providing an order confirmation to the cardholder. 

29. The apparatus of claim 27 further further comprising 
means to record the transaction in a financial institution 
purchase log. 

30. A computer software product for use by a purchasing 
processor operated by a cardholder, the computer software 
product for conducting a financial transaction between the 
cardholder and a merchant, wherein the cardholder makes a 
purchase from the merchant using credit established at a 
financial institution, the computer software product includes 
a medium readable by the purchasing processor, the medium 
having stored thereon: 

a first sequence of instructions which, when executed by 
said purchasing processor, causes said purchasing pro- 
cessor to receive information about the purchase and a 
merchant identifier; and 

a second sequence of instructions which, when executed 
by said purchasing processor, causes said purchasing 
processor to transmit a request to pay to the financial 
institution, the request to pay includes the information 
about the purchase, the merchant identifier and a card- 
holder identifier and instructs the financial institution to 
purchase a selected item for the cardholder. 

31. The medium of claim 30 further comprising: 

a third sequence of instructions which, when executed by 
said purchasing processor, causes said purchasing pro- 
cessor to receive confirmation information about the 
purchase; and 

a fourth sequence of instructions which, when executed 
by said purchasing processor, causes said purchasing 
processor to store the confirmation information in a 
purchasing log on the purchasing processor. 

32. A method of performing a financial transaction allow- 
ing a cardholder to make a purchase from a merchant using 
credit established at a financial institution, the method 
comprising: 

transmitting a merchant offer from the merchant to the 
cardholder, wherein the merchant offer includes mer- 
chant information about the merchant and the purchase; 

transmitting the merchant information and cardholder 
information from the cardholder to the financial insti- 
tution; 

transmitting payment for the purchase from the financial 
institution to a merchant account; 

sending a purchase request from the financial institution 
to the merchant, said purchase request including a 
payment notification indicating that payment for the 
purchase has been made; 

sending to the selected shipper, a cardholder address and 
information about the merchant and items associated 
with the purchase; 

providing items associated with the purchase from the 
merchant to the selected shipper, wherein the items are 
to be shipped by the selected shipper; and 

shipping the items from the selected shipper to the card- 
holder at the cardholder address. 

33. A method of performing a financial transaction allow- 
ing a first cardholder to make a purchase from a second 
cardholder using credit established at a financial institution, 
the method comprising: 

transmitting an offer from the second cardholder to the 
first cardholder, wherein the offer includes information 
about the second cardholder and the purchase; 
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transmitting at least a portion of the offer and first 
cardholder information from the first cardholder to the 
financial institution; 
transmitting payment for the purchase from the financial 

institution to an account of the second cardholder; and 5 
sending a purchase request from the financial institution 
to the second cardholder, said purchase request includ- 
ing a payment notification indicating that payment for 
the purchase has been made and that the second card- 
holder offer has been accepted. 10 
34. A method of performing a financial transaction allow- 
ing a first party to make a purchase from a second party 
using credit established al a financial institution, the method 
comprising: 

transmitting an offer from the second party to the first 
party, wherein the offer includes information about the 
second party and the purchase; 

transmitting at least a portion of the information about the 
second party and information about the first party from 2 o 
the first party to the financial institution, wherein the 
financial institution uses the information about the 
second party and the information about the first party to 
determine whether the offer and/or the purchase are 
authorized; 25 

transmitting payment for the purchase from the financial 
institution to an account belonging the second party; 
and 

sending a purchase request from the financial institution 
to the second party, the purchase request including at 
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least a portion of the offer and a payment notification, 
wherein the portion of the offer is used to match up the 
purchase request with the purchase, and the payment 
notification is used to indicate that payment for the 
purchase has been made and that the offer has been 
accepted, and wherein the purchase request does not 
contain any information relating to the identity of the 
first party. 

35. The method of claim 34 wherein the first party is a 
cardholder and the second party is a merchant. 

36. The method of claim 34, further comprising a step of 
confirming that the first party has enough credit at the 
financial institution to pay for the purchase. 

37. The method of claim 34, further comprising a step of 
verifying that the second party is authorized to receive 
payment for the purchase from the financial institution. 

38. The method of claim 34, wherein the payment noti- 
fication includes a purchase identifier and a first party 
address, and further comprises a step of shipping purchased 
items from the second party to the first party address. 

39. The method of claim 34, wherein the step of sending 
the purchase request comprises steps of: 

sending a purchase identifier from the financial institution 
to the second party; and 

sending shipping information from the financial institu- 
tion to the second party. 
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